1. Field of the Invention
The invention relates generally to computer systems that concurrently execute plural application programs on a preemptive multitasking basis.
The invention is directed more specifically to multitasking systems wherein the execution of a given application program may become frozen or may otherwise halt unexpectedly and for which it is desirable revive the frozen/-halted application program at least partially so as to enable nonvolatile saving of work product produced so far by the frozen program. The invention is directed even more specifically to the problem of how to appropriately save work product items of a just-revived application program.
2a. Cross Reference to Related Patents
The disclosures of the following U.S. patents are incorporated herein by reference:
(A) U.S. Pat. No. 5,911,060 issued Jun. 8, 1999 to Scott Elliott, and entitled, COMPUTER METHOD AND APPARATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM; and
(B) U.S. Pat. No. 5,974,249 issued Oct. 26, 1999 to Scott Elliott et al, and entitled, ZERO FOOTPRINT METHOD AND APPARATUS FOR EXPANDING ALLOCATED MEMORY SPACE OF A PROCESS USING A VIRTUAL MEMORY AREA.
2b. Cross Reference to Co-Pending Patent Applications
The disclosures of the following Co-pending, U.S. patent applications (each owned by the owner of the present application) are incorporated herein by reference:
(A) U.S. Ser. No. 08/938,204, filed Sep. 26, 1997, by inventor Scott Elliott and originally entitled COMPUTER METHOD AND APPARATUS FOR ACCESSING AN APPLICATION PROGRAM WHICH HAS BECOME UNRESPONSIVE TO MESSAGES FROM THE OPERATING SYSTEM OR INCURRED A FATAL ERROR, which application later issued as U.S. Pat. No. 6,009,258; and
(B) U.S. Ser. No. 09/275,171, filed Mar. 24, 1999 as a divisional of U.S. Ser. No. 08/937,629, filed Sep. 26, 1997 by inventor Scott Elliott and originally entitled COMPUTER METHOD AND APPARATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM.
2c. Copyright Notice
This application includes one or more listings of computer programs. The assignee of the present application claims certain copyrights in said computer program listings. The assignee has no objection, however, to the reproduction by others of these listings if such reproduction is for the sole purpose of studying it to understand the invention. The assignee reserves all other copyrights in said program listings including the right to reproduce the corresponding computer programs in machine executable form.
3. Description of Related Art
Multitasking computer systems may be characterized as those that allow multiple programs to execute in overlapping fashion so that it appears the programs are all running at the same time.
Preemptive multitasking systems may be characterized as those in which an operating system (OS) has supervisory control over the concurrently executing programs and the OS limits the length of time that each given application program has for using system resources such as a CPU (Central Processing Unit) or other data processing means.
Examples of preemptive multitasking OS""s include Microsoft Windows95(trademark), Microsoft Windows98(trademark) and Microsoft Windows NT(trademark), all of which are available from Microsoft Corporation of Redmond, Wash. These OS""s also permit multi-threaded execution of programs. In multi-threaded execution, a program begins executing as a first, main thread and optionally generates ancillary threads that run concurrently and interact with one another through exchanges of semaphores.
During execution, a given application program may encounter an unexpected problem which halts its normal execution either in a main thread or an ancillary thread. Examples of causes for such problems include those in which: (a) the program attempts to access restricted (privileged) or unavailable areas of memory areas, (b) the program makes calls to unavailable system functions or services without the ability to handle such unavailability, (c) the program jumps into a nonsense stream of execution code, (d) the program invokes a no-time-out wait for an event that never happens, (e) the program enters into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes.
When such execution-halting events occur, artisans sometimes refer to the halted program as being xe2x80x98stuckxe2x80x99 or xe2x80x98frozenxe2x80x99 or xe2x80x98crashedxe2x80x99 or as having encountered a xe2x80x98fatal errorxe2x80x99. Different flavors of these terms are sometimes associated to one class of cause as opposed to another. Here, the terminology xe2x80x98frozen applicationxe2x80x99 will be generically applied to any and all situations in which the user of a given application program reasonably believes the program is stuck and therefore prevents saving of work product irrespective of the exact cause and irrespective of whether that belief is accurate in fact.
The end-user (e.g., novice user) of a computer system typically doesn""t care what the specific cause is that has led him or her to believe that they can no longer save work product. Such a user instead generally recognizes the xe2x80x98frozenxe2x80x99 condition as an apparently sudden refusal by the given application program to respond appropriately to keyboard strokes or to mouse clicks or to other user interface interactions (which interactions can include voice commands, hand gestures, and so forth).
The presence of a frozen program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other, concurrently-executing application programs can continue to run in normal fashion even though a given application has actually become frozen or has actually crashed (as opposed to situations where the program is fine and the user merely believes it has become stuck). The end-user continues to have access to operating system services and to the resources of non-frozen application programs. (For example, in a Windows95/98(trademark) environment the user may hit the Alt-Tab key combination to switch to the next task.) The user may choose to simply end the tasking of the apparently-frozen program and to thereafter restart the program afresh from its basic start-up state.
Sometimes, this close-and-restart_afresh option is not an attractive one for the end-user. It may be that the end-user did not, or believes he did not, save to nonvolatile memory (e.g., to hard disk), a segment of work that he/she last performed with the application just before the given application became frozen. Closing-and-restarting the frozen program afresh may mean that the unsaved work may be lost forever. Many hours of work may have to be painfully redone to reconstruct the state of the application just before it apparently became frozen. In some instances, the pre-freeze state of the application may represent non-replicatable work product such as data that had just been captured and/or transformed in real-time.
To remedy this predicament, various un-freezing techniques have been developed. These try to revive the frozen/crashed program at least to a sufficient level such that unsaved work product may be accessed and saved either wholly or partially. Examples of such un-freezing techniques include those disclosed in the above-cited patents and patent applications.
No currently known revival technique is 100% effective for all possible forms of application program. One may make an analogy to attempts to revive a human patient by CPR (cardio-pulmonary resuscitation) after the patient suffers a cardiac arrest. In some cases, the patient is fully revived. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient regretfully prove unsuccessful. In so far as reviving a frozen application program is concerned, the end goal is not to keep the application program alive and working as long as possible, but rather to keep it alive long enough so that vital, but still unsaved, work product can be saved.
One un-freezing technique tests the apparently-frozen application to see if the cause of the freeze is a xe2x80x98soft eventxe2x80x99 (where the application continues to respond to messages from the OS) or a xe2x80x98hard eventxe2x80x99 (where the application is not longer responding to messages from the OS). If it is a xe2x80x98soft eventxe2x80x99, the un-freezing technique may try to CLOSE or CANCEL the currently xe2x80x98activexe2x80x99 window under the theory that such an xe2x80x98activexe2x80x99 window is simply a hidden dialog box that is expecting a user response, but is not getting it because the user does not see the hidden dialog box.
If the cause of the freeze is determined to be a xe2x80x98hard eventxe2x80x99, the un-freezing technique may try to continue the execution of the frozen application program by entering the execution stream of the frozen program at a point where continued execution will probably preserve the application""s state just before the encounter with the freeze-causing event. However, even if this attempt is fully or partially successful, determining specifically what data within the revived program should be saved and exactly how to go about saving it is still a problem.
Conventionally, after a revival technique is applied to a xe2x80x98hardxe2x80x99 failure event, a message is sent to the user to go ahead and try to immediately save their work product to nonvolatile memory and to then immediately shut down the application program. In some instances, the end user finds that these instructions are very easy to follow. The application program appears to be fully resuscitated and the end user may quickly forget that the program just suffered a serious problem. The user may be able to easily maneuver the cursor to a SAVE FILE function on the program""s menu bar and invoke a file saving operation. Sometimes the user may be so lucky as to be able to continue working as if nothing wrong had just happened, although such continuing of work defies the instructions given to the user.
In other cases, the end user""s ability to follow the post-revival instructions turns out to be more complicated. The end user may find that the mouse-driven SAVE FILE function of the program has become inoperative. The user may not know what else to do for saving the work product data. Also, the user may have multiple spreadsheets or multiple other work product objects (e.g., word processor documents) left open and in need of saving. The user may become confused and try to use inoperative parts of the just-revived program instead of immediately saving all unsaved work product.
The present invention provides methods and systems which may be used as automated alternatives to allowing an end user to manually control the work product saving process in a just-revived program.
A number of separate aspects of a multi-threading, windows-oriented operating system (OS) are employed here. These include: detection of a possible freeze and attempted revival of an apparently-frozen program, analysis of the parent/child windows hierarchy in the just-revived program, and automatically passing of messages to appropriate child windows to cause those windows to themselves save their data contents and/or immediately thereafter close.
When an un-freeze request is presented, and a Vital Save(trademark) option is selected (VitalSave(trademark) is a trademark of Symantec Corp.), an appropriate revival procedure (which could include doing nothing) is automatically selected and carried out. Thereafter, an automatic identification is made of one or more windows of the just-revived program that most probably contain (immediately in such identified windows), vital data that the user would most likely want to save. One or both of a SAVE and CLOSE message is automatically sent to each identified one of the vital-data containing windows so as to cause that window to itself save its own vital-data, and thereafter optionally close itself.
A machine-implemented, vital-data saving method in accordance with the invention comprises the steps of: (a) attempting to revive a program that has apparently become frozen and identifying that apparently-frozen program; (b) identifying one or more windows within the identified program that are most likely to immediately contain therein data which the user is likely to consider as vital and in need of saving; (c) sending one or both of a SAVE and a CLOSE command message to each of the identified one or more windows so as to thereby cause that window to itself save its vital data contents and to thereafter optionally close itself.
Other features and aspects of the invention will become apparent from the below detailed description.